Although Axway Activator has no inherent limitations on the size of the messages it can process, a number of factors – singly or in combination – can affect the capacity for handling large documents.
Activator can handle very large messages of 2 gigabytes or more.
The following topics are points to consider if you want to trade very large documents.
Disk space requirements can become very large because Activator creates multiple copies of each message.
The temporary directory, generally located on the local file system, must be large enough to contain multiple copies of each message.
The backup directory must be large enough to hold multiple copies of each message. For example, by default a backup is kept of both the raw “consumed” file and the “packaged” or “unpackaged” file, depending on whether you are sending or receiving. These copies may remain in the backup directory for many days, depending on the purge interval.
The storage associated with the integration pickup and delivery exchanges must be sufficient to hold one copy of each message that is sent or received.
Certain transports have special considerations for large messages. Check with your vendor regarding considerations for third-party transports such as JMS providers.
The following considerations apply for transport clients and servers embedded in Activator.
If you know that your partner’s server supports restarts, you may want to enable the Attempt restarts option for the associated delivery exchanges. This enables the transfer to continue where it was interrupted, rather than starting over from the beginning. In the case of FTP you also can enable restarts for pickup exchanges.
Sending a message larger than 2 gigabytes can result in problems if chunking is not enabled. For this reason, when Activator sends a message larger than 2 gigabytes, it automatically enables chunking for that message, even if chunking is disabled for the partner’s HTTP delivery exchange.
Virtually all modern HTTP/1.1-compliant servers support chunking, including the embedded server used by Activator. But if a partner’s server does not support chunking, and you need to trade messages larger than 2 gigabytes, your partner must upgrade his server.
You should request asynchronous receipts from partners if you are trading messages larger than a few megabytes. Failure to do so could result in response time-outs on the client or server or idle time-outs in firewalls or gateways in the connection chain. This is due to the potentially long period in which the connection may appear idle while the server is unpacking the message until it can return the synchronous receipt. Problems related to timed-out connections can be difficult and time-consuming to diagnose. If you know beforehand about trading even one large message, change your AS2 collaboration settings to request asynchronous receipts before you have problems.
Beginning with version 5.4.2, Activator automatically adjusts the response time-out for synchronous receipts on both the client and server side to an appropriate value based on the size of the message.
In previous versions the response time-out was fixed at 30 minutes on the server side. On the client side it could be adjusted manually on the Advanced tab for the delivery exchange, but only to a fixed value that was not suitable for both large and small messages.
This change allows trading large messages that request synchronous receipts to be more reliable. Nevertheless, you are strongly encouraged to request asynchronous receipts to avoid potential time outs in external network components that are beyond your control.
If you expect to receive large messages, adjust your firewall idle time-out accordingly.
For example, if your partners send large AS2 messages that request synchronous receipts (not recommended), you must set your idle time-out to be longer than it takes Activator to unpack the largest message and return the response.
Your partner also must make similar adjustments to receive large messages from you.
With multi-gigabyte messages, the time required to return a synchronous receipt could be hours or days, depending on factors such as the speed of the hardware and system load. Even when requesting asynchronous receipts, the message must be copied to the backup directory before the HTTP response can be returned. If the backup directory is on the network, this could take several minutes. Contact your firewall administrator to ensure the time-out is set appropriately based on the types of receipts being requested and the size of the messages.
There is a general belief that FTP is better than HTTP for large messages. If asynchronous receipts are requested and firewall idle time-outs are set appropriately, there is no reason to prefer FTP over HTTP. This is the case particularly when both parties are using Interchange or Activator, which support restarts over HTTP as well as FTP.